Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/app/`(service)/(my)/class-payment-management/page.tsx:
- Line 239: Replace the hardcoded Tailwind color utilities "from-rose-500
to-rose-300" used in the div with className "h-1000 w-1000 flex-shrink-0
rounded-150 bg-gradient-to-br from-rose-500 to-rose-300" by the project's theme
gradient token defined in global.css (e.g., a bg-fill-brand-* or the appropriate
gradient token); edit that className to remove the literal color utilities and
apply the single theme token class so the component relies on `@theme` inline
tokens rather than hardcoded Tailwind colors.

In `@src/app/`(service)/(my)/my-class/page.tsx:
- Line 204: The conditional divider uses a raw Tailwind color ('bg-rose-200')
which violates the project's styling tokens rule; in the expression
className={cn('h-px', isEnabled ? 'bg-rose-200' : 'bg-border-default')}, replace
'bg-rose-200' with the appropriate project custom token class defined in
global.css (the same token used elsewhere for active/primary dividers in
src/app, e.g., the project's "active divider" or "accent" token) so both
branches use project tokens instead of raw Tailwind colors.
- Around line 42-46: The component reads localStorage during initial render
which causes SSR/CSR mismatch; change the useState initializer for
locallyDisabled to a constant default (e.g., false) and add a useEffect that, on
mount, reads localStorage.getItem(NOTIFICATION_DISABLE_KEY) and calls
setLocallyDisabled accordingly (use the existing locallyDisabled and
setLocallyDisabled identifiers). Also replace hardcoded Tailwind color classes
(e.g., bg-rose-200, bg-gray-200) used in this file with semantic theme tokens
defined in global.css (create/consume classes like bg-accent-weak or bg-muted
that map to your CSS variables) so the component uses the theme tokens instead
of direct color utilities.

In `@src/app/`(service)/(my)/my-inquiry/page.tsx:
- Around line 39-40: The page currently treats a failed fetch as empty because
it only reads `inquiries` from useGetMyOneToOneInquiries(); update the component
to detect and handle the query error instead of rendering the “no inquiries”
empty state: use the error information returned by the hook (or catch the
rejection) and pass it to the centralized error handler in
utils/error-handler.ts (which will use useToastStore) rather than calling alert
or silently rendering an empty list; ensure both the initial query
(useGetMyOneToOneInquiries) and the related code at the other occurrence (lines
~69-73) call the same handler and render an error UI or loading state until data
is valid.
- Around line 95-96: The detail query call using useGetMyOneToOneInquiryDetail
(with expanded ? inquiry.oneToOneInquiryId : null) currently only handles
loading/success and leaves the panel empty on failure; update the component to
read the hook's error state (e.g., isError and error) alongside detail and
detailLoading, call the centralized error handler from utils/error-handler.ts
(and/or useToastStore) to report the error, and render an explicit
error/fallback UI in the panel (a brief error message or retry button) when
isError is true so the user doesn’t see an empty panel; apply the same pattern
to the related rendering block around the 139-173 area.

In `@src/app/`(service)/(my)/my-posts/page.tsx:
- Line 248: Replace the forbidden Tailwind arbitrary class "aspect-[3/2]" on the
<div className="relative aspect-[3/2] w-full bg-gray-100"> JSX element in
page.tsx with the project’s predefined aspect-ratio token/utility (e.g., the
project's aspect token such as aspect-<token> or ratio-<token>); locate that JSX
node (in the default export component of page.tsx) and swap the arbitrary value
for the correct token/utility class used across the codebase.
- Around line 110-131: The three filter buttons in my-posts page.tsx (the
buttons with visible labels "코스", "레슨", and "최신순") are purely presentational and
need either real handlers or a disabled visual state; fix by wiring them to
state and handlers (e.g., add a useState like selectedFilter/setSelectedFilter
and a handleFilterClick that toggles "코스" vs "레슨", and a
selectedSort/setSelectedSort + handleSortClick for "최신순", then pass
onClick={handleFilterClick("코스")} etc. and update rendering based on selected
values), or if the feature isn’t ready, add disabled and aria-disabled
attributes and apply a dimmed class (e.g., opacity-50, cursor-not-allowed) to
each button so they are visually and semantically non-interactive; ensure
accessibility attributes (aria-pressed or aria-disabled) reflect the chosen
approach.
- Around line 78-79: Replace hardcoded Tailwind color classes in the conditional
className (the ternary that returns 'border-b-2 border-rose-500 text-rose-500'
vs 'font-designer-20r text-gray-800') and the other occurrences mentioned (the
lines using 'border-rose-300' and 'hover:text-red-500') with the project’s
design token classes defined in global.css; locate the conditional that sets
those class strings in src/app/(service)/(my)/my-posts/page.tsx and swap each
color class (border-rose-500, text-rose-500, border-rose-300,
hover:text-red-500, text-gray-800 as appropriate) for the equivalent token-based
classes (the token names used elsewhere in global.css) so styling follows the
token convention.

In `@src/types/schemas/inquiry.schema.ts`:
- Around line 26-29: The inquiryContent string schema currently uses .min(1)
which allows strings containing only whitespace; update the schema for
inquiryContent to reject whitespace-only input by trimming or validating
whitespace before length check—for example, apply .transform(s => s.trim()) then
.min(1, '내용을 입력해 주세요.') or use .refine(s => s.trim().length > 0, { message: '내용을
입력해 주세요.' }) so the schema behavior matches the form's trim logic.

---

Outside diff comments:
In `@src/app/`(service)/(my)/my-inquiry/write/page.tsx:
- Around line 50-53: The image input currently only updates local state via
handleImageChange and setImages and never uploads files or attaches generated
keys to requests, so temp-save/submit always send inquiryAttachmentKeys: [];
either wire the upload/key-issuance flow so selected files are uploaded and
their attachment keys are stored and included in the payloads used by the
tempSave and submit handlers, or disable/hide the attachment UI until that flow
exists; specifically update handleImageChange and the images state to call your
upload function that returns keys (or map files→keys), store those keys (e.g.,
attachmentKeys state), and ensure the temp-save/submit routines reference
attachmentKeys instead of always sending an empty array (or conditionally
render/disable the file input element until implemented).

---

Nitpick comments:
In `@src/app/`(service)/(my)/my-posts/page.tsx:
- Around line 249-256: Validate feed.thumbnailUrl against the app's allowed
remote image patterns before passing it to the Next.js <Image> component: add or
use a common URL guard (e.g., isAllowedRemoteImage or validateRemoteImageUrl) to
check feed.thumbnailUrl; only render <Image src={feed.thumbnailUrl} ...> when
the guard returns true and imgError is false, otherwise render the placeholder
fallback; keep the onError handler to flip setImgError(true) but do not rely on
it as the primary validation and ensure the guard uses the same remotePatterns
defined in next.config (or a central export) so allowed domains stay in sync.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/components/payment/modals/class-refund-request-modal.tsx`:
- Around line 132-136: The onChange currently force-casts the dropdown value
with a bare assertion (onChange={(v) => setReason(v as
CourseRefundReasonCode)}); remove the bare as and perform a runtime guard
against valid REFUND_REASONS before calling setReason. Implement a small type
guard that checks whether the incoming v matches one of the known REFUND_REASONS
values (or has the expected discriminant/shape), then call setReason with the
narrowed value; if the guard fails, set a safe fallback (e.g., undefined or a
default reason). Update the SingleDropdown onChange to use this guard and
fallback instead of the bare cast, referencing SingleDropdown, REFUND_REASONS,
reason, setReason, and CourseRefundReasonCode.

In `@src/hooks/queries/course/course-api.ts`:
- Around line 974-987: The current useGetMyDraftBuilderFeeds hook always returns
an empty list because enabled: false and a hardcoded queryFn; fix by wiring it
to an actual readiness flag and/or real API: replace enabled: false with a
conditional flag (e.g., isBuilderFeedsAvailable or isBackendReady) and update
queryFn inside useGetMyDraftBuilderFeeds to call
axiosInstanceV5.get('members/me/builder-feeds/draft') and return data.content
when that flag is true, otherwise keep returning the placeholder ({ feeds: [],
totalCount: 0 }) but ensure the UI checks the same flag (or a returned status)
to show “준비 중” or hide the feature instead of silently showing an empty list;
reference useGetMyDraftBuilderFeeds, queryFn, queryKey and enabled when making
the change.
- Around line 310-329: The mutation useRequestCourseRefund currently only
handles success and leaves failures unhandled; add an onError handler to the
useMutation options that routes the caught error through the project's error
handler and toast store: call the shared error handler from
utils/error-handler.ts (or its exported function) and then use useToastStore to
show a user-facing message when mutationFn for paymentId /
CourseRefundCreateRequest fails, keeping existing onSuccess
(queryClient.invalidateQueries(['myCoursePayments'])) intact; reference the
useRequestCourseRefund function, mutationFn, onError, useToastStore, and
utils/error-handler.ts when making the change.

---

Outside diff comments:
In `@src/app/`(service)/(my)/my-posts/page.tsx:
- Around line 410-417: The code renders next/image with feed.thumbnailUrl when
feed.thumbnailUrl && !imgError which can throw at render if the remote host
isn't allowed by next.config.images.remotePatterns; before rendering the <Image>
in the component (the block using feed.thumbnailUrl, imgError, Image, and
setImgError) validate the URL's hostname (and protocol/path if needed) against
the canonical allowed-host list used in next.config (e.g., img1.kakaocdn.net,
lh3.googleusercontent.com, test-api.zeroone.it.kr, api.zeroone.it.kr,
www.zeroone.it.kr, *.r2.cloudflarestorage.com, localhost variants) and only
render <Image src={feed.thumbnailUrl} ... /> when it matches, otherwise render
the existing fallback div; also replace the hardcoded tailwind/bg class
"relative aspect-[3/2] w-full bg-gray-100" with a class or token referenced from
global.css (use the global CSS variable/token for the background color) so
styling uses the design tokens instead of arbitrary values.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/app/`(service)/(my)/my-posts/page.tsx:
- Around line 457-461: The editHref currently builds slug routes using
feed.courseId which can break slug-based routing; update the logic around
editHref (used where feed.courseId, feed.lessonId, feed.feedId are referenced)
to prefer feed.courseSlug when present and fall back safely (e.g., render no
link or a disabled/placeholder link) while the slug is not available, or ensure
the API returns courseSlug and use that to construct `/class/${courseSlug}` and
`/class/${courseSlug}/lesson/${feed.lessonId}?feedId=${feed.feedId}`; make sure
link rendering checks feed.courseSlug before outputting a slug route to avoid
broken links.